"is epic a thing here?"

Let's look at current list at https://github.com/cypht-org/cypht/issues and see if some would qualify. Would these qualify?

• Improve the UX of the Sieve filter editor #1308
• There is a trillion themes... #1354
• [Proposal for Cypht 3.0] Enhance Cypht UI with Customized Bootstrap 5 and jQuery 3.7.1 #1256
• What can we learn and implement from the Docker strategy of other webmail project? #1146
• The WYSIWYG editor used by Cypht "has been archived by the owner on Jan 9, 2024. It is now read-only." #1136
• Rethinking Hm_Functions #1048

"Is devops needed?"

Maybe for tasks like this: #1175

"is epic a thing here?"

Let's look at current list at https://github.com/cypht-org/cypht/issues and see if some would qualify. Would these qualify?

• Improve the UX of the Sieve filter editor #1308
• There is a trillion themes... #1354
• [Proposal for Cypht 3.0] Enhance Cypht UI with Customized Bootstrap 5 and jQuery 3.7.1 #1256
• What can we learn and implement from the Docker strategy of other webmail project? #1146
• The WYSIWYG editor used by Cypht "has been archived by the owner on Jan 9, 2024. It is now read-only." #1136
• Rethinking Hm_Functions #1048

Epic is normally a greater goal, which then is comprised of several features. An example would be: "Provide an native android App" or "Implement AI driven E-Mail writing".

Of the list you provide

• Improve the UX of the Sieve filter editor #1308 does not quality since its an improvement
• There is a trillion themes... #1354 is a bugreport, but refactoring themes could be an epic with each specific theme a feature.
• [Proposal for Cypht 3.0] Enhance Cypht UI with Customized Bootstrap 5 and jQuery 3.7.1 #1256 seems appropriate, but could also be a Release type.
• What can we learn and implement from the Docker strategy of other webmail project? #1146 is more research and would qualify as Question type.
• Rethinking Hm_Functions #1048 could be an epic, but also a question

In general I use Epic and Release types for planning purposes - normally users don't create those issue, but Project leads, eg. to define the scope of an upcoming release. This utilizes issues to track progress and have strategic notes/goals available for everyone. I am unsure this project qualifies for this kind of approach.

"Is devops needed?"

Maybe for tasks like this: #1175

I think the linked issue would qualify for this - I tend to use Devops for everything related to the sorroundings of the project, like deployments, backups or github related things (this PR would qualify for this type). I am not 100% sure this projects qualifies for this, since except the website there is no deployments actively maintained by the project itself.

Please decide what you need and I will adjust the PR accordingly. If you need more info, I can try to help.

Another approach could be to provide all types and see how people use them - but that's something the project maintainers then need to do.

Another thing: The PR title validation contains a regex, which enforces PRs to start with a lower case character after its scope and type definitions(see here) - this tends to confuse people and is there for the sake of visual pleasure in a changelog.

Valid: type(scope): my PR title
Invalid: type(scope): My PR title

This utilizes issues to track progress and have strategic notes/goals available for everyone. I am unsure this project qualifies for this kind of approach.

This is a community project so everyone is welcome to collaborate at all levels, including strategic.

Since I am invested in testing cypht lately

@ulfgebhardt: This is highly appreciated. In the last year, we have seen a record number of contributors: https://openhub.net/p/cypht/contributors/summary

Lots of new features
Lots of devs that are new to the code base (and don't have a lot of experience using Cypht)

So I feel 1.4.x is more stable than 2.x (and even more so master)

Over the next few months, the focus will increasingly be on fixing bugs. So we really need testers. So your help is deeply appreciated.

Epic is normally a greater goal, which then is comprised of several features.

I like this concept, and since we have examples, I think we should keep.

@ulfgebhardt

Recently, I added "technical debt" on another bug tracker:
https://tiki.org/blogpost984-Added-a-category-for-technical-debt-on-dev-tiki-org

How would deal with a task of this type? For example: #1136

Create all labels for the types decided for

Indeed, labels should aligned. Can you please review current labels and recommend which ones should be added / removed / merged?

Thanks!

• Do you want the PR title workflow?

I am undecided. Let's see what others say.

@ulfgebhardt

Recently, I added "technical debt" on another bug tracker: https://tiki.org/blogpost984-Added-a-category-for-technical-debt-on-dev-tiki-org

How would deal with a task of this type? For example: #1136

This I would qualify as Refactor, since it improves/changes existing code without changing behaviour.

Create all labels for the types decided for

Indeed, labels should aligned. Can you please review current labels and recommend which ones should be added / removed / merged?

Thanks!

The following labels are used by the templates, strikethrough are already present in the Repo:

• bug
• devops
• epic
• feature
• question
• refactor
• release

Hence, when all templates are merged devops, epic, feature, refactor and release should be created to automatically assign this label when an issue is created. If the label is not present, no label is automatically assigned.

• Do you want the PR title workflow?

I am undecided. Let's see what others say.

Since you seem not to require tests to pass (selenium is failing, but my branch can be merged) this decision can also be postponed and checked if things work as you expect - then the workflow can be made a requirement

Since I am invested in testing cypht lately

@ulfgebhardt: This is highly appreciated. In the last year, we have seen a record number of contributors: https://openhub.net/p/cypht/contributors/summary

Lots of new features Lots of devs that are new to the code base (and don't have a lot of experience using Cypht)

So I feel 1.4.x is more stable than 2.x (and even more so master)

Over the next few months, the focus will increasingly be on fixing bugs. So we really need testers. So your help is deeply appreciated.

To increase stability you need more tests and you MUST make them reliable - flaky tests as I see them in this project are not helping - they undermine the developers trust in the tests. It is very important, that a developer knows he did something wrong if he fails a test - he must be able to rely on that. It will make it easier for developers & for maintainers to judge if code is working correctly. Furthermore beginners are able to get automatic feedback from the development environment about their work without bothering people about it.

I might be able to assist with that if I find the time.

Test milestones would be:

• remove flakyness
• require coverage goal
• enforce code style via linting
• static analysis via linting
• >95% test coverage
• fullstack tests

This I would qualify as Refactor, since it improves/changes existing code without changing behaviour.

works for me

The following labels are used by the templates

I added to https://github.com/cypht-org/cypht/labels

this decision can also be postponed and checked if things work as you expect

works for me

this decision can also be postponed and checked if things work as you expect

works for me

Feel free to merge then unless you want more feedback.

I might be able to assist with that if I find the time.

This is fantastic! With guidance, our several keen and young developers will learn and improve tests.

Feel free to merge

Was going to merge but the selenium tests are failing so I just relaunched them.

Still failing but merged anyways.

Regarding the PR title validation, I think it's a great thing people should consider. However, without clear documentation on what constitutes a valid title, the entire process becomes counterproductive. Many PRs are now struggling to pass this validation, and those that do often rely on the author's guesswork.

Most importantly, what scopes are being validated against? For instance, when using the scope frontend, the validation fails with the message: Unknown scope "frontend" found in pull request title....

@ulfgebhardt, could you please look into making this validation criteria more explicit?